目次
はじめに
こんにちは！山内です。
最近いろんな所で話題となっている「バイブコーディング（Vibe Coding）」、皆さんはもう試しましたか？
「バイブコーディング」とは、AIに細かい指示を出すのではなく、自然言語でふわっとした要望（Vibe）を伝え、AIと阿吽の呼吸でコーディングを進めていくスタイルのことです。
今回はこの手法を使って、「Git学習Webアプリ」の開発にチャレンジしました。
きっかけは、現場でシステムエンジニアの新人さんと接する中で「Gitの概念、特にGit-flowやファイルの状態遷移（Staging/Unstaging）の理解につまずいているな」と感じることが多かったからです。
もちろん、世の中には優れた学習サービスがたくさんあります。しかし、実際に新人教育に使ってみると、「Git-flowの運用ルール」と「ファイル単位の状態遷移」をセットで直感的に学べるものとなると、意外と見当たらないんですよね。
「ブランチを切るタイミングで、ファイルの状態がどうなっているか見せたい」「もっと現場の運用に即した可視化がほしい…」
そんな、既存サービスでは微妙に”痒い所に手が届かない”もどかしさがずっとありました。
「ないなら作ってしまおう。でも時間はかけたくない」
そこで今回は、制限時間1時間という縛りを設け、バイブコーディングでゼロからAWS環境へのデプロイまでをどこまで進められるか検証してみました！
※画面やバージョン情報は執筆時点（2025年12月12日）のものです。
今回の環境と前提
今回は「思い立ったらすぐ開発」というテーマなので、PCにすでにインストール済みのツール類をフル活用します。
＜前提＞
- パッと使える生成AIサービスおよびAWS環境が手元にある状態でスタート
- IDE（VSCode）や生成AIサービス、各種言語やコマンド（AWS CLIなど）は作業PCにインストール済み
- WSL環境にて開発
＜バージョン情報＞
- VSCode：v1.107.0
- Gemini Pro：v3（思考モード）
- Kiro CLI：v1.22.0
- OpenAI：ChatGPT 5.2
- AWS CLI：aws-cli/2.31.22
チャレンジ開始！実績タイムライン
先に結果が気になる方は「おわりに」のすぐ上あたりを読んでください！
ここからは、Gemini（要件定義・UI）とKiro CLI（実装・デプロイ）をどう使い分けたか、実際のプロンプトと共に振り返ります。
では、よーい、スタート！
1. 【Gemini】仕様整理（スタート ～ 09:20）
まずはGemini Pro v3（思考モード）を使って、作りたいアプリのアイデアを壁打ちします。
「こんな課題感があるんだけど、どういう仕様が良い？」と、まさにVibe（雰囲気）を伝えます。
＜プロンプト#1-1＞
|
1 2 3 |
システムエンジニアの新人がGitの理解を深めるのに時間を費やしてしまうと感じる。 Git-flowに準拠しつつ、Git管理下の各ファイルの状態が視覚化され、理解を促進するような学習Webアプリを作成したい。 どのような仕様の考慮が必要かな？ |
＜プロンプト#1-1の応答＞ ※抜粋
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
素晴らしいアイデアですね。Gitは概念（特に「今、ファイルがどこにあるのか」）が不可視であるため、新人は「コマンドのおまじない化」に陥りがちです。 Git-flowの作法」と「ファイル状態の遷移」の2点を同時に視覚化することで、本質的な理解を促すWebアプリの仕様案をご提案します。 # 1. 画面構成と視覚化（UI/UX仕様） - A. 4つのエリア（ステージ）の常時表示 - B. Git-flow ネットワークグラフ（樹形図） # 2. インタラクションと操作仕様 - A. コマンド入力 vs GUI操作 - B. リアルタイム・ステータス表示 # 3. Git-flow 学習シナリオ（カリキュラム機能） - Feature開発の流れ - Release作業 - Hotfix # 4. 技術的な考慮事項 Webアプリとして実装する際の技術選定のヒントです。 - Frontend: React または Vue.js。状態管理（State Management）が複雑になるため、ReduxやPiniaなどで「Gitの内部状態（ファイルの状態、ブランチのポインタ）」を厳格に管理する必要があります。 - Gitエンジンの模倣: 本物のGitをバックエンドで動かすより、JavaScriptでGitの挙動をシミュレートするライブラリ（例: isomorphic-git や独自の簡易ロジック）を使用する方が、視覚化のためのデータフックが容易で、サーバー負荷も低くなります。 |
Geminiからの提案は非常に具体的でした。
「Working Tree」「Index」「Repository」のエリアを可視化することや、コマンド入力とGUI操作のハイブリッドなどを提案してくれました。
応答を見ていて、さらに学習効果を高めるために「レベルデザイン」の概念を導入することを思い付きました。
＜プロンプト#1-2＞
|
1 2 3 4 5 6 |
もう少し要件を整理したい。 いきなりジャンプアップしても身につかないので、徐々に問題のランク・レベルを上げていく感じにしたい。 最初のランク「初級」ではコマンドは使わずに、視覚的にドラッグ＆ドロップで問題をクリアしていく感じ。問題レベルも基本コマンドのみ。 次のランク「中級」ではコマンドを使って、問題レベルとしては開発フローとして、featureブランチを作成してからdevelopブランチにfeatureブランチをマージするまでをやらせたい。必要に応じて視覚化サポートあり。 最後のランク「上級」では、コマンドで開発あるあるの競合解決やGit管理下からの除外、gitignoreなどを学ばせたい。 |
これに対しGeminiは、次の構成案を返してくれました。また、技術的な構成として「Gitエンジンはブラウザ（JS）でシミュレーションする」というアーキテクチャもここで決定しました。
壁打ちしていく中で、今回は検証の意味合いも強く、「リッチなGitエンジンは不要」という結論に至ったためです。
＜プロンプト#1-2の応答＞ ※抜粋
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
段階を踏んで学習レベルを上げる「レベルデザイン」の導入、非常に良いアプローチですね！ ゲームのようにステップアップさせることで、挫折率を大幅に下げることができます。 ご提示いただいたランクに合わせて、以下の仕様を提案します。 # ランク1：【初級】概念の視覚化（No Command / Drag ＆ Drop） - 目的: コマンドを打たせず、「ファイルがどこにあるか」というメンタルモデルを構築する。 - ギミック: 画面を「作業場」「梱包場」「倉庫」などに分割。ファイルをドラッグ＆ドロップだけで移動させ、add や commit の意味を直感的に理解させる。 # ランク2：【中級】Git-flowの基本（Command + Visual Support） - 目的: 基本コマンドとGit-flowのサイクル（ブランチ作成→開発→マージ）を習得する。 - ギミック: ここからコマンド入力を解禁。コマンドを打つたびに、画面上の「ブランチ樹形図」がリアルタイムに伸びたり合流したりするアニメーションを入れる。 # ランク3：【上級】トラブルシュート（Real World Scenarios） - 目的: 現場で必ず直面する「困った状態」を安全に経験させる。 - ギミック: 意図的に「コンフリクト」を発生させて解消させたり、.gitignore でファイルを管理から外すなど、実践的なトラブル対応を学ばせる。 この「理屈（初級）」→「作法（中級）」→「対処（上級）」の構成なら、無理なくスキルアップできるはずです。 |
念のため、モック作成にあたって考慮不足な点がないかを聞いてみました。
結果、「ない」とのことだったのでこれにて仕様整理は完了としました。
＜プロンプト#1-3＞
|
1 2 3 |
この後画面モックを作成してもらおうと思いますが、それに当たって不足している情報はありますか？ なければ「ない」と答えてください。 その後タスク着手の指示を出します。 |
ここまで9分20秒、もう1/6を使ってしまいました。果たして間に合うのでしょうか…！？
2. 【Gemini】モック作成（09:20 ～ 24:06）
要件が見えたので、次はUIのイメージを固めます。
ここからはGeminiのCanvas機能を使いました。
＜プロンプト#2-1＞
|
1 |
モック作成に着手してください。 |
＜プロンプト#2-1の応答＞
この時点でかなり良い感じのモックを作ってくれました！
ただ、まだ盛り込みたい要素があったのと、基本的なGit操作系で漏れがないか心配だったので追加指示を出します。
＜プロンプト#2-2＞
|
1 2 3 4 5 6 |
各ランクにおいて下記の考慮を加えたい。 他に基本的なGit操作で追加したほうが良い要素あるかな？ # 追加要素 - Working Directoryへの追加判定 - ブランチの作成とマージ |
＜プロンプト#2-2の応答＞
|
1 2 3 4 5 6 7 8 |
ご提示いただいた「Working Directoryへのファイル追加・変更フロー」および「ブランチの作成とマージ」は、Gitの理解において最も重要な部分ですね。これらを実装に組み込みます。 また、他に基本的な操作として追加すべき要素として、以下の3点を提案します。これらも可能であれば学習シナリオに含めると、より実践的になります。 1. git status: 「今、自分がどういう状況か？」を文字情報で確認する癖をつけるため、中級以上では頻繁に使わせるべきです。 2. git diff: 「何を変えたか？」を add する前に確認する習慣です。 3. .gitignore: 「管理したくないファイル（ログや設定ファイル）」を除外する設定です。これも初心者がよく失敗するポイントです。 今回は、ご要望の**「ファイル追加/変更アクション」と「ブランチ/マージ操作」を実装し、さらにgit status**の概念も少し取り入れた形にバージョンアップします。 |
そういえば、新人は「クローン」の時点でイメージが付きづらそうにしていました。
リモートとローカルの区別をしっかりつけてほしいので、追加してもらいます。
また、まとめて1つの問題とするより、各コマンドを1つずつステップアップできるように問題として扱ってもらえるようにします。
他にも色々と追加指示を出して都度モックを修正してもらいました。
＜プロンプト#2-3＞
|
1 2 |
「クローン」も追加したい。 あと、初級からちゃんと1ステップごとに「問題」としたい。 |
＜プロンプト#2-3の応答＞
かなりこちらの希望通りになってきました！
ただ、結構時間をかけてしまいましたね…。この先不安です、頑張らないと！
3. 【Gemini/OpenAI】仕様書作成＆整形（24:06 ～ 25:56）
モックができたら、Kiro CLIで実装するための仕様書を出力してもらいます。
Geminiの回答がマークダウン記法だと自動ハイライトされてしまったため、ここで一旦、ChatGPT 5.2にスイッチし、Geminiが出力したテキストをKiro CLIが読み込める形式のMarkdown仕様書に整形させました。
複数のAIを用途に合わせて使い分けるのも、バイブコーディングの”ミソ”ですね。
＜プロンプト#3-1＞ ※Geminiへ
|
1 |
今回の画面モックとこれまで整理した仕様をマークダウンファイルにまとめてください。 |
＜プロンプト#3-2＞ ※ChatGPTへ
|
1 |
次のテキストをマークダウン記法で表現してください。 |
＜プロンプト#3-2の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 |
# プロジェクト概要 ## アプリケーション名 - Git-Mastery Road（仮） ## 目的 - システムエンジニアの新人研修において、GitおよびGit-flowの理解不足（コマンドのおまじない化）を解消する。 - 「ファイルの状態遷移」と「ブランチの構造」を視覚化し、体験型の学習を提供することで、正しいメンタルモデルの構築を支援する。 ## コンセプト - **不可視なものの可視化**: 通常は見えないGit内部の状態（インデックス、HEADの位置など）を常時表示する。 - **段階的学習（レベルデザイン）**: 直感的な操作から入り、徐々に実践的なコマンド操作へステップアップさせる。 - **失敗の許容**: コンフリクトや誤操作を安全な環境で体験・リカバリーさせる。 --- # 学習ランク設計（レベルデザイン） 学習進度に合わせて3つのランク（モード）を用意する。 ## Rank 1: 初級（概念・ストーリー体験） - **ターゲット**: Gitを初めて触る層。 - **操作方法**: ドラッグ＆ドロップ（GUI）のみ。コマンド入力不要。 - **学習ゴール** - 4つのエリア（Working, Staging, Local, Remote）の役割理解。 - add, commit, push によるファイル移動のイメージ定着。 - 基本フロー（Clone → Edit → Add → Commit → Push）の体験。 - **特徴**: ストーリー形式のミッションガイドに従って操作する（正解ルート以外はガイドで修正）。 ## Rank 2: 中級（Git-flow・コマンド操作） - **ターゲット**: 基本概念はわかるが、ブランチ運用に不安がある層。 - **操作方法**: 擬似コマンドライン入力（git checkout, git merge 等）+ GUI補助。 - **学習ゴール** - ブランチの作成と切り替え（Checkout）。 - Git-flow（develop, feature）の運用フロー体験。 - マージによる履歴の統合イメージの理解。 ## Rank 3: 上級（トラブルシュート・実践） - **ターゲット**: 実践的なトラブル対応を学びたい層。 - **学習ゴール** - コンフリクト（競合）の解消。 - .gitignore や git rm --cached などの管理系操作。 - （将来実装）rebase や cherry-pick などの高度な操作。 --- # 画面仕様（UI/UX） 画面は大きく3つのセクションで構成される。 ## ヘッダーエリア - **アプリタイトル**: Git-Mastery Road - **ランク切り替え**: 初級 / 中級 / 上級 のモード切替タブ。 - **リセットボタン**: 現在のシミュレーション状態を初期化する。 ## 環境可視化エリア（メインビュー） ファイルの現在地を示す4つのゾーンを表示。「ローカル（自分のPC）」と「リモート（サーバー）」の境界を明確に区切るデザインを採用。 ### [Local Environment (Your Computer)] - **Working Directory**: 作業場。ファイルの新規作成・編集を行う。 - **Staging Area**: インデックス。コミット候補を置く場所。 - **Local Repository**: ローカル倉庫。コミット履歴が記録される場所。 ### [Connection] - Push / Pull の矢印。 ### [Remote Environment (GitHub/Server)] - **Remote Repository**: 共有倉庫。チーム全員が参照する場所。 ### [インタラクション] - ファイルをドラッグ＆ドロップで次のゾーンへ移動可能（擬似的な add, commit, push）。 - ファイルの状態（Untracked, Modified, Staged, Committed）をアイコンや色で表現。 ## 情報・操作エリア（ボトムビュー） ### [Git Network Graph（左側）] - **樹形図**: コミットログをネットワークグラフ（SVG）でリアルタイム描画。 - **レーン表示**: master, develop, feature の役割ごとのレーンを表示。 - **ブランチメニュー**: 現在のブランチ表示と、切り替え（Checkout）・作成（Create）を行うドロップダウンメニュー。 ### [Terminal / Mission Console（右側）] - **ミッションガイド**: 初級ランクでの「次の指示」を表示。 - **操作ログ**: 実行したアクション（git commit ... 等）や結果、エラーメッセージの履歴表示。 - **コマンド入力欄**: 中級以上で有効化されるCUI入力フォーム。 --- # 機能要件 ## 擬似Gitエンジン（フロントエンド実装） 本物のGitではなく、JavaScriptのオブジェクト（State）としてGitの状態をシミュレートする。 - **ファイル管理**: 各ゾーンにおけるファイルの有無とステータス管理。 - **コミット管理**: 親子関係を持つコミットノードのデータ構造と、HEADポインタの管理。 - **ブランチ管理**: ブランチ名と参照コミットIDのマッピング。 ## シナリオ・ミッション機能 初級ランクにおけるステップ進行管理。 1. Step 1: Clone 2. Step 2: Checkout develop 3. Step 3: Create feature branch 4. Step 4: Create File 5. Step 5: Add 6. Step 6: Commit 7. Step 7: Push ## コマンドパーサー（中級以上） 入力された文字列を解析し、擬似Gitエンジンの状態を更新する。 - **対応コマンド例** - `git clone [url]` - `git status` - `git add .` / `git add [file]` - `git commit -m "[msg]"` - `git checkout [branch]` / `git checkout -b [branch]` - `git push` - `git flow feature start [name]`（エイリアス対応） --- # 技術スタック・アーキテクチャ（想定） ## フロントエンド - **Framework**: React（TypeScript） - **Styling**: Tailwind CSS - **Icons**: Lucide React - **Deployment**: AWS S3 + CloudFront（SPA Hosting） ## バックエンド（将来的な拡張） 現在はフロントエンドのみで完結しているが、学習履歴の保存や管理者機能のために以下を想定。 - **Architecture**: AWS Serverless - **Compute**: AWS Lambda（Node.js） - **Database**: Amazon DynamoDB（ユーザー進捗、セーブデータ保存） - **Auth**: Amazon Cognito（ユーザー認証） --- # 最新モックアップの実装状況（App.tsx の現状） - **UI**: 1ファイル（App.tsx）で完結するReactコンポーネントとして実装済み。 - **可視化**: ローカル/リモートのエリア分け、SVGによるネットワークグラフ描画を実装。 - **ロジック** - Rank 1のストーリー進行ロジック実装済み。 - D&Dによるファイル移動と状態遷移の実装済み。 - 基本的なコマンドラインパーサーの実装済み。 - **ブランチ** - メニューからのブランチ切り替え、featureブランチ作成機能を実装。 |
ここまででもう約半分が過ぎました…！
本当にデプロイまで達成できるのでしょうか…。
4. 【Kiro CLI】フロントエンド実装（25:56 ～ 44:35）
仕様が固まったので、ここからは実装パートです。
GeminiとChatGPTが出力した仕様書（SPEC.md）とモックアップ（mock.tsx）を、Kiro CLIに読み込ませます。
＜プロンプト#4-1＞
|
1 2 |
SPEC.mdおよびmock.tsxの全容を把握してください。 このWebアプリを構築したいので、まずは最小構成の環境セットアップをしてください。 |
＜プロンプト#4-1の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
環境セットアップが完了しました！Git-Mastery Roadアプリケーションが正常に起動しています。 ## セットアップ完了内容 1. プロジェクト構成 - React 18 + TypeScript + Vite - Tailwind CSS（スタイリング） - Lucide React（アイコン） 2. ファイル構成 /home/tdi5277/projects/miso-git-study/ ├── package.json ├── vite.config.ts ├── tsconfig.json ├── tailwind.config.js ├── postcss.config.js ├── index.html └── src/ ├── main.tsx ├── index.css └── App.tsx (mock.tsxからコピー) 3. 開発サーバー起動済み - URL: http://localhost:5173/ - ホットリロード対応 ## アプリケーション機能 - **3つの学習ランク**: 初級（GUI操作）、中級（コマンド入力）、上級（トラブルシュート） - **Git状態の可視化**: Working Directory、Staging Area、Local Repository、Remote Repository - **ドラッグ＆ドロップ操作**: ファイルの状態遷移を直感的に体験 - **ブランチ管理**: Git-flowに基づくブランチ操作 - **コミット履歴グラフ**: SVGによるネットワークグラフ表示 ブラウザで http://localhost:5173/ にアクセスしてアプリケーションを確認できます。 |
やばい…！間に合え…！！
5. 【Kiro CLI】バックエンド実装（44:35 ～ 50:22）
ここが今回のハイライトです。
フロントエンドは動きましたが、学習データを保存するためのバックエンドが必要です。ここも「Vibe」で依頼します。
＜プロンプト#5-1＞
|
1 2 |
現状の最小構成において、DB化およびAPIすべき部分はどこでしょうか？ リストアップしてください。 |
＜プロンプト#5-1の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 |
## DB化すべきデータ ### 1. ユーザー進捗管理 typescript // 現在: ローカルstate const [missionStep, setMissionStep] = useState＜number＞(0); const [rank, setRank] = useState＜Rank＞('beginner'); // DB化対象 interface UserProgress { userId: string; currentRank: Rank; missionStep: number; completedMissions: string[]; lastAccessDate: Date; } ### 2. セッション状態の永続化 typescript // 現在: ローカルstate（リロードで消失） const [files, setFiles] = useState＜FileItem[]＞([]); const [commits, setCommits] = useState＜CommitNode[]＞([]); const [branches, setBranches] = useState＜Branch[]＞([]); const [currentBranch, setCurrentBranch] = useState＜string＞('master'); // DB化対象 interface SessionState { sessionId: string; userId: string; files: FileItem[]; commits: CommitNode[]; branches: Branch[]; currentBranch: string; isCloned: boolean; createdAt: Date; updatedAt: Date; } ### 3. 学習履歴・ログ typescript // 現在: ローカルstate const [logs, setLogs] = useState＜Log[]＞([]); // DB化対象 interface LearningLog { logId: string; userId: string; sessionId: string; action: string; result: 'success' | 'error' | 'info'; timestamp: Date; rank: Rank; missionStep: number; } ## API化すべき機能 ### 1. ユーザー管理API - POST /api/auth/login - ユーザー認証 - GET /api/users/{userId}/progress - 進捗取得 - PUT /api/users/{userId}/progress - 進捗更新 ### 2. セッション管理API - POST /api/sessions - 新規セッション作成 - GET /api/sessions/{sessionId} - セッション状態取得 - PUT /api/sessions/{sessionId} - セッション状態保存 - DELETE /api/sessions/{sessionId} - セッション削除 ### 3. 学習履歴API - POST /api/logs - アクションログ記録 - GET /api/users/{userId}/logs - 学習履歴取得 - GET /api/analytics/progress - 進捗分析（管理者用） ### 4. コンテンツ管理API - GET /api/missions/{rank} - ミッション定義取得 - GET /api/templates/repositories - 初期リポジトリテンプレート ## 最小構成での優先順位 Phase 1（必須）: 1. ユーザー進捗の永続化 2. セッション状態の保存・復元 Phase 2（推奨）: 3. 学習履歴の記録 4. 基本的な分析機能 Phase 3（将来拡張）: 5. 管理者機能 6. 高度な分析・レポート機能 |
Kiro CLIがソースコードを分析し、「ユーザー進捗管理」「セッション状態の永続化」「学習履歴・ログ」の3つが必要だと提案してくれました。
個人的に、問題もマスタテーブルとして管理したかったので、追加で聞いてみました。
＜プロンプト#5-2＞
|
1 |
問題（ミッション）関連はどうでしょうか？ |
＜プロンプト#5-2の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 |
問題（ミッション）関連のDB化・API化すべき部分をリストアップします： ## 現在のミッション実装（ハードコード） ### 1. ミッション定義がコード内に固定 typescript // 現在: ハードコード const getMissionText = () =＞ { if (rank !== 'beginner') return "自由課題: featureブランチ運用やコンフリクト解消を練習しましょう。"; switch (missionStep) { case 0: return "Step 1: 【Clone】ボタンを押して、リモートリポジトリをローカルに複製してください。"; case 1: return "Step 2: グラフエリアのブランチメニューから【develop】を選択し、チェックアウトしてください。"; // ... } }; ### 2. ミッション進行ロジックが分散 typescript // 現在: 各操作関数内に分散 if (rank === 'beginner' ＆＆ missionStep !== 3) { addLog('まだその操作は早いです。現在のミッションを確認してください。', 'error'); return; } ## DB化すべきミッション関連データ ### 1. ミッション定義 typescript interface Mission { id: string; rank: Rank; step: number; title: string; description: string; instructions: string; expectedActions: string[]; validationRules: ValidationRule[]; hints: string[]; nextMissionId?: string; } interface ValidationRule { type: 'file_in_zone' | 'branch_checkout' | 'commit_created' | 'command_executed'; condition: any; errorMessage: string; } ### 2. ミッションテンプレート typescript interface MissionTemplate { id: string; name: string; description: string; initialState: { files: FileItem[]; commits: CommitNode[]; branches: Branch[]; currentBranch: string; }; missions: Mission[]; } ### 3. ユーザーミッション進捗 typescript interface UserMissionProgress { userId: string; missionId: string; status: 'not_started' | 'in_progress' | 'completed' | 'failed'; attempts: number; completedAt?: Date; timeSpent: number; hintsUsed: string[]; errors: string[]; } ## API化すべきミッション機能 ### 1. ミッション管理API - GET /api/missions/templates - 利用可能なミッションテンプレート一覧 - GET /api/missions/templates/{templateId} - 特定テンプレートの詳細 - GET /api/missions/{rank} - ランク別ミッション一覧 - GET /api/missions/{missionId} - 特定ミッションの詳細 ### 2. ミッション進行API - POST /api/users/{userId}/missions/{missionId}/start - ミッション開始 - POST /api/users/{userId}/missions/{missionId}/validate - アクション検証 - PUT /api/users/{userId}/missions/{missionId}/progress - 進捗更新 - POST /api/users/{userId}/missions/{missionId}/complete - ミッション完了 ### 3. ヒント・ヘルプAPI - GET /api/missions/{missionId}/hints - ヒント取得 - POST /api/users/{userId}/missions/{missionId}/hint - ヒント使用記録 ### 4. 管理者用API - POST /api/admin/missions - 新規ミッション作成 - PUT /api/admin/missions/{missionId} - ミッション更新 - GET /api/admin/missions/analytics - ミッション分析データ ## 最小構成での優先順位 Phase 1（必須）: 1. ミッション定義のDB化 2. 基本的なミッション進行API Phase 2（推奨）: 3. ミッション検証ロジックの外部化 4. ユーザー進捗追跡 Phase 3（将来拡張）: 5. 動的ミッション作成機能 6. 高度な分析・レポート |
提案内容に合意したので、そのままAWS CDKでの構築を依頼します。
＜プロンプト#5-3＞
|
1 |
推奨機能までのDBとAPIをAWSにCDKで用意したいです。フォルダ構成も必要に応じて変更したい。計画を立ててください。不足情報があれば聞いてください。 |
＜プロンプト#5-3の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
## 確認事項 1. 認証方式: Amazon Cognito User Pools を使用しますか？それとも別の認証方式を希望しますか？ 2. データベース: DynamoDB（NoSQL）で問題ありませんか？RDS（SQL）を希望しますか？ 3. API: REST API（API Gateway + Lambda）で良いですか？GraphQL（AppSync）は必要ですか？ 4. デプロイ環境: 開発環境のみ？本番環境も考慮しますか？ 5. フロントエンドホスティング: S3 + CloudFront で静的ホスティングで良いですか？ ## 提案する構成 ### アーキテクチャ Frontend (React) → API Gateway → Lambda → DynamoDB ↓ Amazon Cognito ### フォルダ構成案 miso-git-study/ ├── frontend/ # 既存のReactアプリ │ ├── src/ │ ├── package.json │ └── ... ├── backend/ # CDK + Lambda │ ├── lib/ │ │ ├── database-stack.ts │ │ ├── api-stack.ts │ │ └── auth-stack.ts │ ├── lambda/ │ │ ├── users/ │ │ ├── sessions/ │ │ ├── missions/ │ │ └── shared/ │ ├── cdk.json │ └── package.json └── shared/ # 共通型定義 └── types/ ### 必要なAWSリソース - **DynamoDB**: Users, Sessions, Missions, UserProgress, Logs - **Lambda**: API handlers - **API Gateway**: REST API - **Cognito**: User authentication - **S3 + CloudFront**: Frontend hosting - **IAM**: 権限管理 上記の確認事項にお答えいただければ、詳細な実装計画を作成します。 |
Kiro CLIから認証方式やDBの種類についていくつか質問が来たので適宜回答し、Lambdaの実装へ進みます。
＜プロンプト#5-4＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
回答します。 他に確認事項がなければ、Lambdaの実装を進めてください。 # 回答 1. 認証方式: Amazon Cognito User Pools を使用しますか？それとも別の認証方式を希望しますか？ 将来的にはCognito、現状は固定ユーザーでも良い 2. データベース: DynamoDB（NoSQL）で問題ありませんか？RDS（SQL）を希望しますか？ DynamoDBで良い 3. API: REST API（API Gateway + Lambda）で良いですか？GraphQL（AppSync）は必要ですか？ API Gateway + Lambdaが良い 4. デプロイ環境: 開発環境のみ？本番環境も考慮しますか？ 開発環境のみで良い 5. フロントエンドホスティング: S3 + CloudFront で静的ホスティングで良いですか？ その構成で良い |
＜プロンプト#5-4の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
## Lambda実装完了 以下のLambda関数を実装しました： ### ユーザー管理 - GET /users/{userId}/progress - ユーザー進捗取得 - PUT /users/{userId}/progress - ユーザー進捗更新 ### セッション管理 - POST /sessions - セッション作成 - GET /sessions/{sessionId} - セッション取得 - PUT /sessions/{sessionId} - セッション更新 ### ミッション管理 - GET /missions?rank={rank} - ミッション一覧取得 - POST /missions/validate - ミッション検証 ### ログ管理 - POST /logs - ログ作成 ## 次のステップ 1. CDKデプロイ - AWSリソースの作成 2. 初期データ投入 - ミッション定義の作成 3. フロントエンド統合 - API呼び出しの実装 CDKデプロイを実行しますか？ |
DB定義やAPI一覧も一緒に検討していたからか、比較的スムーズに実装してくれました。
あと10分、行けるぞ！
あと10分、行けるぞ！
6. 【Kiro CLI】バックエンドのデプロイ（50:22 ～ 53:17）
AWS CDKを使ってインフラをデプロイします。
＜プロンプト#6-1＞ ※5-4の応答に対して
|
1 |
はい。SSOプロファイル「xxxxxx」を使ってください。 |
＜プロンプト#6-1の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
CDKデプロイが成功しました！🎉 ## デプロイ完了 ### 作成されたリソース DynamoDB テーブル: - git-mastery-users - ユーザー情報 - git-mastery-sessions - セッション状態 - git-mastery-missions - ミッション定義 - git-mastery-user-progress - ユーザー進捗 - git-mastery-logs - 学習ログ Lambda関数: - ユーザー進捗管理 (GET/PUT) - セッション管理 (POST/GET/PUT) - ミッション管理 (GET/POST) - ログ管理 (POST) API Gateway: - **API URL**: https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/ ### 利用可能なエンドポイント GET /users/{userId}/progress PUT /users/{userId}/progress POST /sessions GET /sessions/{sessionId} PUT /sessions/{sessionId} GET /missions?rank={rank} POST /missions/validate POST /logs ## 次のステップ 1. 初期データ投入 - ミッション定義の作成 2. API動作確認 - 基本的なテスト 3. フロントエンド統合 - React側でAPI呼び出し実装 どの作業から進めますか？ |
これで、DynamoDBテーブル5つ、Lambda関数4つ、API Gatewayが自動的にデプロイされました。
応答は数秒だったので、実質的にはCloudFormationの稼働時間くらいしかかかっていません。
このペースであれば行けるか！？
7. 【Kiro CLI】データ投入・フロント統合・デプロイ（53:17 ～ ??:??）
残り時間約7分！
テストデータを入れ、フロントエンドと結合して公開します。ラストスパート！
＜プロンプト#7-1＞
|
1 |
初期データを投入し、APIの動作を確認してください。 |
＜プロンプト#7-1の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
初期データ投入が完了しました。 現在の状況: - ✅ DynamoDB テーブル作成済み - ✅ Lambda関数デプロイ済み - ✅ API Gateway設定済み - ✅ 初期データ投入完了 ## API動作確認結果 ✅ 全てのAPIが正常に動作しています！ ### テスト結果サマリー | API | エンドポイント | ステータス | レスポンス | |-----|---------------|-----------|-----------| | ミッション取得 | GET /missions?rank=beginner | ✅ 成功 | 7件のbeginnerミッション | | ユーザー進捗取得 | GET /users/{userId}/progress | ✅ 成功 | 初期進捗データ | | セッション作成 | POST /sessions | ✅ 成功 | 新規セッション作成 | | セッション取得 | GET /sessions/{sessionId} | ✅ 成功 | セッション状態取得 | | ログ作成 | POST /logs | ✅ 成功 | ログエントリ作成 | | ミッション検証 | POST /missions/validate | ✅ 成功 | 検証結果返却 | ### 確認されたデータ ミッション定義: 7つのbeginnerステップが正常に取得 ユーザー進捗: test-user-001の初期状態が正常 セッション管理: 作成・取得が正常動作 ログ機能: アクション記録が正常動作 検証機能: ミッション進行チェックが正常動作 ## 次のステップ API動作確認が完了しました。次は： 1. フロントエンド統合 - React側でAPI呼び出し実装 2. エラーハンドリング強化 - より詳細なエラー処理 3. パフォーマンス最適化 - レスポンス時間改善 フロントエンド統合に進みますか？ |
APIの動作は問題なさそうなので、フロントエンドと統合します。
＜プロンプト#7-2＞
|
1 |
フロントエンド統合に進みます |
＜プロンプト#7-2の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
フロントエンドが起動しました！ ## フロントエンド統合完了 ✅ ### 実装した機能 API統合: - ✅ ユーザー進捗の取得・更新 - ✅ セッション状態の管理 - ✅ ミッション定義の取得 - ✅ 学習ログの記録 - ✅ リアルタイム状態同期 React Hooks: - useUserProgress - ユーザー進捗管理 - useSession - セッション状態管理 - useMissions - ミッション取得 統合された機能: - API経由でのミッション表示 - 進捗の永続化 - セッション状態の自動保存 - アクションログの記録 ### アクセス方法 フロントエンド: http://localhost:5173/ API: https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/ ### 動作確認 ブラウザで http://localhost:5173/ にアクセスして以下を確認できます： 1. 初期データ読み込み - APIからミッション定義を取得 2. 進捗管理 - ユーザーの学習進捗が保存される 3. セッション管理 - アプリの状態がリアルタイムで同期 4. ログ記録 - 全てのアクションがバックエンドに記録 フロントエンド統合が完了しました。アプリケーションが正常に動作することを確認してください！ |
ここでReact側のコードが書き換えられ、API Gatewayのエンドポイントと接続されました。
ブラウザをリロードすると、ユーザーの進捗がDynamoDBに保存されるようになり、本格的なWebアプリの挙動になりました。
最後はS3 + CloudFrontへのデプロイです。
＜プロンプト#7-3＞
|
1 |
フロントエンドをS3+CloudFrontにデプロイをお願いします。 |
＜プロンプト#7-3の応答＞
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
## フロントエンドデプロイ完了！🎉 ### デプロイされたリソース S3バケット: - git-mastery-frontend-xxxxxxxxxx - 静的ウェブサイトホスティング設定済み CloudFront配信: - Distribution ID: xxxxxxxxxx - HTTPS対応、グローバル配信 - SPA用エラーハンドリング設定済み 公開URL: - **https://xxxxxxxxxx.cloudfront.net** ### 設定された機能 ✅ HTTPS強制リダイレクト ✅ SPA対応 - 404/403エラーをindex.htmlにリダイレクト ✅ キャッシュ最適化 - 静的アセットの効率的な配信 ✅ 自動デプロイ - CDKによるビルド成果物の自動アップロード ✅ グローバル配信 - CloudFrontによる世界規模の高速配信 ### アクセス方法 本番環境: https://xxxxxxxxxx.cloudfront.net API: https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/ ### 完全なアーキテクチャ [ユーザー] ↓ HTTPS [CloudFront] ↓ [S3 Static Website] ← React SPA ↓ API calls [API Gateway] ↓ [Lambda Functions] ↓ [DynamoDB Tables] Git-Mastery Roadアプリケーションが完全にAWSクラウドにデプロイされました！ ブラウザで https://xxxxxxxxxx.cloudfront.net にアクセスして動作を確認してください。 |
Kiro CLIがビルドを実行し、S3へのアップロードとCloudFrontのキャッシュ無効化までを自動で行いました。払い出されたURLにアクセスすると…無事、アプリが動いています！
果たしてタイムは…！？
58分11秒！ギリギリ1時間切りです。
おわりに
今回は「バイブコーディング」でGit学習アプリの1時間タイムアタック開発チャレンジをやってみました。
感想としては、「作りたいもののイメージ（Vibe）さえ明確なら、実装コストは劇的に下がる」ということです。
特に以下の点が「ミソ」でした。
- Geminiの思考モード: 「初級・中級・上級」といったレベルデザインや、「Gitのシミュレーションロジック」などの設計部分を丸投げできた。
- Kiro CLIのインフラ構築力: Reactのコードから必要なAPIを逆算し、CDKのコードを書いてデプロイまで自律的に行うスピード感が凄まじかった。
これなら、新人の理解度に合わせて「次はRebaseの練習モードを追加しよう」といった改善もすぐに回せそうです。
皆さんもぜひ、業務の課題解決にバイブコーディングを取り入れてみてください！
以上、参考になれば幸いです。
執筆者プロフィール
- tdi デジタルイノベーション技術部
- 社内の開発プロジェクトの技術支援や、Javaにおける社内標準フレームワークの開発を担当しています。Spring BootとTDDに手を出しつつ、LINE Botとかもいじったりしています。最近はマイクロサービスを勉強しつつ、クラウドアプリケーションを開発できるエンジニアの育成にも力を入れてます！
